home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / networking / athena / misc / filsys.doc < prev    next >
Encoding:
Text File  |  1991-12-23  |  9.4 KB  |  179 lines
  1.                       FILESYSTEM CLEANLINESS ACT OF 1991
  2.                                       OR
  3.                    FILESYSTEM REORGANIZATION FOR RELEASE 7.3
  4.  
  5. No Problem!
  6.                                         Athena Faculty Liaison
  7.  
  8. Everyone will know where everything is; it will be wonderful!
  9.                                         Athena Systems Support Supervisor
  10.  
  11. With  this  release,  we  are supporting three new platforms: RS/6000 with AIX,
  12. Macintosh with A/UX, and DECstations with Ultrix 4.2.  One of the  difficulties
  13. in  Athenizing  a  vendor  operating system is deciding where to put the Athena
  14. additions and replacements of vendor-supplied programs.
  15.  
  16. This topic is  properly  part  of  the  VOSAP  (vendor  operating  systems  and
  17. platforms) discussion which we have not had time to start yet.  Changes between|
  18. the version originally sent around for comments and what  was  decided  at  the|
  19. review are noted by changebars.                                                |
  20.  
  21. 1 Motivation
  22. By  making this change now, there are no backward-compatibility requirements on
  23. the three new platforms.  If we delay this change, we will have  such  problems
  24. on all of our platforms.
  25.  
  26. It should be possible to layer Athena software on a machine already running the
  27. vendor operating system.  For this reason, Athena files should be  added  to  a
  28. small number of places, not scattered across the entire operating system.  Even
  29. for machines where Athena operations controls the system software,  it  is  far
  30. easier  for  release-engineering  to  put  together  the  release if the Athena
  31. changes are limited.  This is also an important  issue  in  re-integrating  our
  32. changes when vendor updates are received.
  33.  
  34. 2 Proposal
  35. Athena  additions are defined as anything we add to the vendor-supplied system,|
  36. whether it was written here or imported.                                       |
  37.  
  38.    1. Most Athena additions will go under  /usr/athena,  making  this  the     |
  39.       mount point for the eventual layered Athena system.  For third-party     |
  40.       software, for the most part we will follow the supplier's  suggested     |
  41.       paths  except that we insert ``/athena'' in the path after ``/usr''.     |
  42.       However, all binaries will go in  one  place  rather  than  creating     |
  43.       /usr/athena/new, /usr/athena/ucb, etc.                                   |
  44.  
  45.          - User binaries will go in /usr/athena/bin.
  46.  
  47.          - Libraries will go in /usr/athena/lib.
  48.  
  49.          - Include files will go in /usr/athena/include.
  50.  
  51.          - Man pages will go in /usr/athena/man.
  52.  
  53.          - System binaries will go in /usr/athena/etc.
  54.  
  55.          - The imake configuration files will go in /usr/athena/config.
  56.  
  57.    2. Some  Athena  additions must be on the root partition for use before
  58.       the  machine  has  come  up  on  the  network  and  mounted   remote
  59.       filesystems.    Other  Athena  additions  must  be on the local disk
  60.       because  they  are  configuration  files  that   may   differ   from
  61.       workstation to workstation.
  62.  
  63.          - User binaries that must be local go in /bin/athena.
  64.  
  65.          - System   binaries   that   must  be  local  go  in  the  athena     |
  66.            subdirectory of where  the  vendor  puts  such  binaries  (i.e.     |
  67.            /etc/athena or /sbin/athena).                                       |
  68.  
  69.          - System configuration files go in /etc/athena.
  70.  
  71.    3. In  some cases Athena must replace a vendor binary with an Athenized
  72.       version.  In most cases we will leave the vendor  binary  in  place,
  73.       and put our version in /usr/athena.  The order of directories in the
  74.       user's PATH will ensure that they get the proper version.   We  will     |
  75.       also  create  a symlink with a different name for the vendor version     |
  76.       (i.e. chsh.aix or lpr.ult) so that  the  user  can  still  name  the     |
  77.       vendor  program.  For replaced programs that are invoked by absolute     |
  78.       pathname (login, lpr, inetd, named, snmpd) we will rename the vendor
  79.       version and leave it in the directory next to our own version.
  80.  
  81. 3 Discussion
  82. The  following  issues  are  examined with three audiences in mind: the student
  83. user in a public cluster, the faculty/staff person owning  a  workstation,  and
  84. the software developer.
  85.  
  86.  
  87.  
  88. 3.1 User Visibility
  89. To   avoid  user  visible  changes  in  this  release,  we  will  put  in  full|
  90. compatibility symlinks on the VAX, RT, and DECstation platforms.  In  addition,|
  91. the  RS/6000  and Macintosh platforms will have compatibility symlinks for user|
  92. binaries, but not for developers.                                              |
  93.                                                                                |
  94. At the time  we  release  this  software,  we  will  notify  users  that  these|
  95. compatibility  links will be removed a year from now, and give them pointers to|
  96. documents for  how  to  fix  their  dotfiles  and  Makefiles.    The  following|
  97. discussion   outlines   changes  that  will  be  visible  when  we  remove  the|
  98. compatibility links.                                                           |
  99.  
  100. For people with dotfile customizations, there are three ways  we  expect  users
  101. might  lose.   One is by using explicit paths, i.e. invoking /usr/bin/X11/xterm
  102. instead of just xterm.  The most universal solution  is  not  to  use  explicit
  103. paths  and  to  relay  on  the  PATH environment variable to find the programs.
  104. Another solution is to update the paths to the new locations, which  will  work
  105. on  all  supported  platforms.    We  have  yet  to investigate the performance
  106. difference of using explicit paths versus using the PATH  environment  variable
  107. in dotfiles.
  108.  
  109. Another  way  people  with customizations may lose is by setting their own PATH
  110. variable rather than by modifying the default one.  People who just add to  the
  111. end  of  athena_path will have no problems.  People who set their own path will
  112. have to be educated to fix this.
  113.  
  114. The third way we expect that some people have  have  problems  is  by  invoking
  115. features that are not on every platform.  For example, people have been told to
  116. put unlimit coredumpsize in their dotfiles  if  they  want  to  get  coredumps.
  117. Other people have put stty dec in their dotfiles.  These commands will not work
  118. on some of the new platforms.  We must educate the  users  and  provide  sample
  119. dotfiles  which  have  examples of machine-specific initializations.  Something
  120. else we could do to combat all three of these problems is to provide  a  script
  121. which analyzes the user's dotfiles and suggests changes.
  122.  
  123. For programmers, there will be other visible changes.  Existing binaries on the
  124. Vax and RT platforms will continue to work.  We will  also  have  compatibility
  125. symlinks  on  Vaxen  and RTs for recompiling working code.  However, to compile
  126. anything on other platforms additional flags will need to be  given  to  cc  to
  127. account  for  the  move  of  include  files and libraries.  These flags will be
  128. forwards compatible on  the  Vaxen  and  RTs.    We  will  be  recommending  to
  129. developers  that  they  use  imake  to avoid these problems.  Documentation for
  130. developers will be available by the time the release hits the field.
  131.  
  132.  
  133.  
  134. 3.2 Backwards compatibility on existing platforms.
  135. Compatibility for Vaxen, RTs,  and  DECstations  will  be  forwards  compatible|
  136. symlinks  rather than actually re-arranging the filesystems and putting in many
  137. backwards compatible symlinks.  In this way, references to the old locations of
  138. files  will  still  work,  and  through  these  symlinks  references to the new
  139. locations will work as well.  The required links are:
  140.  
  141.     /usr/athena/bin -> /usr/athena
  142.     /usr/athena/include -> /usr/include
  143.     /usr/athena/etc -> /etc/athena
  144.     /usr/athena/third/bin -> /usr/new
  145.     /usr/athena/third/lib -> /usr/lib
  146.     /usr/athena/X11/bin -> /usr/bin/X11
  147.     /usr/athena/X11/lib -> /usr/lib/X11
  148.     /usr/athena/X11/include -> /usr/include/X11
  149.  
  150. The remainder of this proposal will not affect users on these  platforms.    It
  151. may  not  ever be worth re-arranging the VAX and RT platforms, although we will|
  152. want to remove these symlinks from the DECstation in a year.                   |
  153.  
  154.  
  155.  
  156. 3.3 Man Pages
  157. We have moved the  Athena  man  pages,  and  mention  the  MANPATH  environment
  158. variable.   As of this writing, the only platform we have that does not support
  159. MANPATH is the DECstation.  On the platform, we have our  own  version  of  man
  160. installed  earlier  in  the  search  path than the Ultrix man.  Keeping the man
  161. pages separate means that it is still possible  to  look  at  the  original  OS
  162. documentation,  and  our  Athena  layering  will  not interfere with what is an
  163. optional subset on many platforms.
  164.  
  165. We will need to add support to the standard dotfiles for an athena_manpath just|
  166. like we do athena_path, and then educate users on how to use these.            |
  167.  
  168.  
  169.  
  170. 3.4 X Integration
  171. Where to put X was a difficult choice.  One argument says that there is already
  172. a standard location for X binaries: /usr/bin/X11.  But if the vendor puts their
  173. own  version of X there, we have a conflict.  And some third party software may
  174. depend on the vendor's version of X clients.  So we put our X  in  a  different
  175. place.   Some vendors already put their X somewhere other than /usr/bin/X11, so
  176. this is not a major departure from standard practice.  Any decision to separate|
  177. X  binaries  from other Athena supplied binaries is somewhat arbitrary, so they|
  178. will go in /usr/athena/bin.                                                    |
  179.